[rfxcom] Add ability to properly receive configured command ids, deprecate hard-coded guesses #10940
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Making draft for now, forgot to clean up how messages are matched to things. |
Jamstah
force-pushed
the
rfxcom-lighting4-rx
branch
2 times, most recently
from
800bb0d to
753361d
Compare
martinvw
reviewed
Jul 6, 2021
...src/test/java/org/openhab/binding/rfxcom/internal/messages/RFXComUndecodedRFMessageTest.java
Outdated
Show resolved
Hide resolved
Jamstah
force-pushed
the
rfxcom-lighting4-rx
branch
2 times, most recently
from
6d62821 to
a120701
Compare
…ecated hard-coded guesses. Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]>
Jamstah
force-pushed
the
rfxcom-lighting4-rx
branch
from
a120701 to
e3de13b
Compare
|
Glad I set to draft, because this wasn't setting the pulse and was crashing the hardware. Now fixed and some extra tests added. This is now ready for review. Once (if) this goes in, I'll add a suitable note to https://github.com/openhab/openhab-distro/blob/main/distributions/openhab/src/main/resources/bin/update.lst. |
martinvw
approved these changes
Jul 18, 2021
|
@Jamstah should this be marked as a bug or enhancement? |
|
Marked where? I'd say enhancement |
Jamstah
added
enhancement
Jamstah
added a commit
to Jamstah/openhab-distro
that referenced
this pull request
Jul 19, 2021
See openhab/openhab-addons#10940 Signed-off-by: James Hewitt-Thomas <[email protected]>
dw-8
pushed a commit
to dw-8/openhab-addons
that referenced
this pull request
Jul 23, 2021
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]> Signed-off-by: dw-8 <[email protected]>
dw-8
pushed a commit
to dw-8/openhab-addons
that referenced
this pull request
Jul 25, 2021
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]> Signed-off-by: dw-8 <[email protected]>
dw-8
added a commit
to dw-8/openhab-addons
that referenced
this pull request
Jul 25, 2021
…ds, deprecated hard-coded guesses. (openhab#10940)" This reverts commit 8352f7a.
dw-8
pushed a commit
to dw-8/openhab-addons
that referenced
this pull request
Jul 25, 2021
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]> Signed-off-by: dw-8 <[email protected]>
dw-8
added a commit
to dw-8/openhab-addons
that referenced
this pull request
Jul 25, 2021
…ds, deprecated hard-coded guesses. (openhab#10940)" This reverts commit 8352f7a. Signed-off-by: dw-8 <[email protected]>
martinvw
pushed a commit
to openhab/openhab-distro
that referenced
this pull request
Aug 23, 2021
See openhab/openhab-addons#10940 Signed-off-by: James Hewitt-Thomas <[email protected]>
dschoepel
pushed a commit
to dschoepel/openhab-addons
that referenced
this pull request
Oct 7, 2021
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]> Signed-off-by: Dave J Schoepel <[email protected]>
frederictobiasc
pushed a commit
to frederictobiasc/openhab-addons
that referenced
this pull request
Oct 26, 2021
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]>
thinkingstone
pushed a commit
to thinkingstone/openhab-addons
that referenced
this pull request
Nov 7, 2021
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]>
marcfischerboschio
pushed a commit
to bosch-io/openhab-addons
that referenced
this pull request
May 5, 2022
…ecated hard-coded guesses. (openhab#10940) Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future. The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities. Signed-off-by: James Hewitt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands.
The hard-coded ON/OFF commands are based on experimentation with different devices, and are not at all consistent. This commit also deprecates the use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong way around, turn ON one physical device and OFF another, or any combination of those possibilities.
Signed-off-by: James Hewitt [email protected]